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ABSTRACT 

Users often wish to participate in online groups anonymously, 
but misbehaving users may abuse this anonymity to spam or 
disrupt the group. Messaging protocols such as Mix-nets and 
DC-nets leave online groups vulnerable to denial-of-service 
and Sybil attacks, while accountable voting protocols are 
unusable or inefficient for general anonymous messaging. 

We present the first general messaging protocol that offers 
provable anonymity with accountability for moderate-size 
groups, and efficiently handles unbalanced loads where few 
members have much data to transmit in a given round. The 
N group members first cooperatively shuffie a.n N x N ma- 
trix of pseudorandom seeds, then use these seeds in A'' "pre- 
planned" DC-nets protocol runs. Each DC-nets run trans- 
mits the variable-length bulk data comprising one member's 
message, using the minimum number of bits required for 
anonymity under our attack model. The protocol preserves 
message integrity and one-to-one correspondence between 
members and messages, makes denial-of-service attacks by 
members traceable to the culprit, and efficiently handles 
large and unbalanced message loads. A working prototype 
demonstrates the protocol's practicality for anonymous mes- 
saging in groups of 40-1- member nodes. 



1. INTRODUCTION 

Anonymous participation is often considered a basic right 
in free societies The limited form of anonymity the 

that Internet provides is a widely cherished feature [331137) 
that enables people and groups with controversial or un- 
popular views to communicate and organize without fear of 
personal reprisal [30]. In spite of its benefits, anonymity 
makes it difficult to trace or exclude misbehaving partici- 
pants [To]. Online protocols providing stronger anonymity, 
such as mix-networks [7|[TH] and DC-nets [51 l28|[55] further 
weaken accountability and yield forums in which no content 
may be considered trustworthy and no defense is available 
against anonymous misbehavior. 

This paper focuses on providing anonymous messaging 
within small, private online groups. We assume a group's 
membership is closed and known to its members; creating 
groups with secret membership is a related but orthogonal 
goal [3J . Members may wish to send messages to each other, 
to the whole group, or to a non-member, such that the re- 
ceiver knows that some member sent the message but no 
one knows which member. Members may also wish to 
cast secret ballots in votes held by the group, or to create 
pseudonyms under which to collaborate with other members. 



We also wish to hold members accountable, however: not 
by compromising their anonymity and allowing some author- 
ity or majority quorum to unmask a member whose messages 
prove unpopular, but rather by ensuring that no malicious 
member can abuse his (strong) anonymity to disrupt the 
group's operation. For example, a malicious member should 
be unable to corrupt or block other members' messages, 
overrun the group with spam, stuff ballots, or create un- 
limited anonymous Sybil identities [14] or sock puppets [32] 
with which to bias or subvert the group's deliberations. 

As a motivating example, suppose an international group 
of journalists wishes to form a "whistleblowing" publication 
like WikiLeaks To protect journalists and their sources 
more strongly than the world's varied legal frameworks do, 
member journalists wish to submit leaked documents and re- 
lated information to the group anonymously. Members need 
assurance that powerful organizations or governments can- 
not trace the leak to an individual journalist or her source. 
The journalists wish to prove to their readers that leaked 
documents come via a trustworthy channel, namely one of 
the group's known and reputable members, and not from 
an outsider. The group must be able to analyze and vet 
each document thoroughly before collectively approving it 
for publication. The group must protect its internal opera- 
tion and its members' anonymity even from adversaries who 
have planted colluding spies within the group. And this se- 
curity must come at acceptable time and resource costs. 

We present an accountable anonymous messaging pro- 
tocol called Dissent (Dining-cryptographers Shuffied-Send 
Network), the first we know of with the properties needed 
in scenarios like the one above. Dissent provides provable 
integrity, anonymity, and accountability in the face of strong 
traffic analysis and compromised members, and an experi- 
mental prototype shows it to be efficient enough for latency- 
tolerant messaging in small but widely distributed groups. 

In contrast with mix-networks [7l[l8] and DC-nets [8l|28j 
I36j . Dissent implements a shujfled send primitive, where 
each group member sends exactly one message per round, 
making it usable for voting or assigning pseudonyms with a 
1-to-l correspondence to real group members. Unlike verifi- 
able cryptographic shuffies [17122) , Dissent uses only readily- 
available cryptographic primitives, and handles arbitrary- 
size messages and unbalanced loads efficiently, such as when 
one journalist has a multi-gigabyte document to leak at a 
time when the others have nothing to send. 

Dissent operates in two stages, shujfle and bulk trans- 
fer. The shuffie protocol builds on a data mining protocol 
by Brickell and Shmatikov [5] to permute a set of fixed- 



length messages, one from each group member, and broad- 
cast the set to aU members with cryptographically strong 
anonymity. Like many anonymous messaging protocols, the 
original data mining protocol was vulnerable to untraceable 
denial-of-service (DoS) attacks by malicious members. Our 
refinements remove this vulnerability by adding go/no-go 
and blame phases, which can trace and hold accountable 
any group member maliciously disrupting the protocol. 

Dissent's bulk protocol builds on the information-theoretic 
anonymity of DC- nets |8I28I36| . but leverages Dissent's shuf- 
fle protocol to replace the DoS-prone slot reservation sys- 
tems in prior DC-nets schemes with a prearranged transmis- 
sion schedule guaranteeing each member exactly one mes- 
sage slot per round. In each round, all group members 
broadcast bit streams based on pseudorandom seeds dis- 
tributed via the shuffle protocol, so that XORing all mem- 
bers' bit streams together yields a permuted concatenation 
of all members' variable- length messages. Cryptographic 
hashes distributed in the shuffle phase enable members to 
verify the correctness of each others' bulk transmissions, en- 
suring message integrity and DoS protection throughout. 

Dissent has limitations, of course. It is not intended for 
large-scale, "open-access" anonymous messaging or file shar- 
ing [51[TS], although it might serve as a building block in 
designs like Herbivore [28]. Dissent's accountability prop- 
erties assume closed groups, and are ineffective if a mali- 
cious member can just leave and rejoin the group under a 
new (public) identity after expulsion. Dissent is also not 
a general-purpose voting system, providing only a limited 
form of coercion resistance for example. The serialized shuf- 
fle protocol imposes a per-round startup delay that makes 
Dissent impractical for latency-sensitive applications. 

We built a working prototype of Dissent, and tested it 
under Emulab [TS] on groups of up to 44 nodes connected 
via simulated wide-area links. Anonymously distributing 
messages up to 16MB in size among 16 nodes with 100ms 
inter-node delays, Dissent's shuffle and other startup costs 
incur a 1.4-minute latency, but it handles large message 
loads, both balanced and unbalanced, in about 3.5 x the 
time required for non-anonymized group messaging via TCP. 
Varying group size, Dissent can send a 1MB message anony- 
mously in less than 1 minute in a 4-member group, 4 minutes 
for a 20-node group, and 14 minutes for a 40-node group. 
While not suitable for interactive workloads, therefore. Dis- 
sent should be usable for "WikiLeaks"-type scenarios requir- 
ing strong security guarantees in small decentralized groups. 

This paper makes four main technical contributions. First, 
we enhance Brickell/Shmatikov's shuffle protocol ^ to make 
DoS attackers traceable without compromising anonymity. 
Second, we use this shuffle protocol to create a DoS-resistant 
DC-nets variant for bulk transfer, which guarantees each 
member exactly one transmission slot per round. Third, we 
introduce the first shuffle protocol that supports arbitrary- 
size and unbalanced message loads efficiently, e.g., when 
only one member has data to send. Fourth, we demonstrate 
through a working prototype the practicality of the protocol, 
at least for delay-tolerant applications. 

Section[2]provides an overview of Dissent's communication 
model, security goals, and operation. Section [3] formally de- 
scribes the shuffle protocol, and Section [4] details the bulk 
protocol. Section [S] informally covers practical implemen- 
tation and usage considerations such as protocol initiation, 
coercion resistance, and liveness. Section [S] describes our 



prototype implementation and experimental results. Sec- 
tion [7] summarizes related work, and Section [8] concludes. 

2. PROTOCOL OVERVIEW 

This section first introduces the group communication model 
our protocol implements, outlines a few applications of this 
model, and defines the protocol's precise security goals, leav- 
ing protocol details to subsequent sections. 

2.1 The Shuffled Send Primitive 

The purpose of Dissent is to provide a shuffled send com- 
munication primitive, providing sender anonymity among 
a well-defined group of nodes. We assume that the set of 
members comprising the group, and each member's public 
key or certificate, is agreed upon and known to all group 
members. The group may initiate a run of the shuffled send 
protocol in any way that preserves anonymity goals: e.g., 
a designated leader, or every group member, might initiate 
runs periodically, or a "client" in or outside the group not 
requiring anonymity might initiate a run to request a ser- 
vice provided by the group collectively. (A member's desire 
to send anonymously must not be the initiation event, if 
traffic analysis protection is desired.) Each protocol run is 
independent and permits each group member to send ex- 
actly one variable-length message to some target designated 
for that run; ongoing interaction requires multiple protocol 
runs. A run's target may be a particular group member, all 
members (for anonymous group multicast), or another node 
such as a non-member "client" that initiated the run. 

Each protocol run operates as shown in Figure [T] Every 
group member i secretly creates a message rm and submits 
it to the protocol. The protocol collects all A'^ secret mes- 
sages, shuffles their order according to some random permu- 
tation TT that no one knows, concatenates the messages in 
this shuffled order so that rui appears at position tt^, and 
sends the concatenated sequence of messages to the target. 
Each input message mi can have a different length Li, and 
the protocol's output has length Li. 

2.2 Applications of Shuffled Send 

The shuffled send model combines and generalizes the 
functionality of several classes of anonymity protocols. Al- 
though every participant must submit a message in a given 
protocol run, members with nothing to send can submit a 
message of length zero, providing efflcient single-sender as 
well as multiple-sender service. (The protocol still causes 
each member to send a similar number of bits on the underly- 
ing network for trafflc analysis protection, but none of these 
bits are wasted padding messages of unbalanced lengths.) 
Members wishing receiver anonymity can first anonymously 
send a public encryption key to establish a pseudonym, then 
look for messages encrypted with that key in subsequent 
shuffled sends targeted at the whole group. 

Since each member may submit exactly one message per 
shuffled send, one run's messages can serve as ballots in an 
anonymous vote. Unlike anonymous voting protocols de- 
signed for specific types of ballots and tallying methods. 
Dissent supports ballots of arbitrary type, format, and size, 
and group members can count and independently verify the 
ballots in any agreed-upon fashion. Ballots need not be one- 
shot messages either: a group can use one protocol run to 
establish a set of pseudonymous signing keys, exactly one 
per member, then use these pseudonyms in subsequent pro- 
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Figure 1: Shuffled send communication model 



tocol runs for pseudonymous deliberation, without permit- 
ting members to create unlimited pseudonyms for Sybil at- 
tacks [14] or sock puppetry |32) . 

Applications for which shuffled send may be suited include 
whistleblowing [38], surveys [5], file sharing [28], accountable 
Wiki-style editing [32], and "cocaine auctions" [29]. The 
current version of Dissent also has limitations: e.g., it may 
not scale to large groups, it provides only a limited form of 
coercion resistance described in Section [5.3l and the latency 
of the shuffle required on each protocol run may make the 
protocol impractical for interactive or real-time messaging. 
Future work may be able to address these limitations. 

2.3 Security Goals 

We now precisely define Dissent's attack model and se- 
curity goals. We assume the attacker is polynomial-time 
limited, but can monitor all network traffic and compro- 
mise any subset of group members. A member is honest 
if she follows the protocol exactly and is not under the at- 
tacker's control, and faulty otherwise. Faulty nodes may col- 
lude and send arbitrary messages. For simplicity, our core 
protocol descriptions in Sections [S] and |3] assume that nodes 
never just go silent; we address liveness using principles from 
PeerReview [T9| as outlined in Section [5] The formal secu- 
rity properties we wish the protocol to satisfy are integrity, 
anonymity, and accountability, as we define below. 

• Integrity: The protocol maintains integrity if at the end 
of a protocol run, every honest member either: (a) obtains 
exactly A'' messages, including exactly one submitted by 
each honest member, or (b) knows that the protocol did 
not complete successfully. 

• Anonymity: Following Brickell and Shmatikov [5], the 
protocol maintains anonymity if a group of < N — 2 
colluding members cannot match an honest participant's 
message to its author with a probability significantly bet- 



ter than random guessing. (If all but one member col- 
ludes, no anonymity is possible.) 

• Accountability: Adopting ideas from PeerReview [19) . 
a member i exposes a member j if i holds third-party ver- 
ifiable proof of j's misbehavior. The protocol maintains 
accountability if no member ever exposes an honest mem- 
ber, and after a run, either: (a) each honest member suc- 
cessfully obtains every honest member's message, or (b) 
all honest members expose at least one faulty member. 

2.4 Protocol Operation Summary 

Dissent consists of two sub-protocols: a shuffle protocol 
and a bulk protocol, whose operation we briefly summarize 
here to provide context for the detailed descriptions in the 
next sections. 

In the shuffle protocol, all members 1, . . . ,N first choose 
secret messages mi, ... , mjv, of equal length L. Each mem- 
ber i now iteratively wraps its message mi in 2N layers of 
public-key encryption using an IND-CCA2 [5] secure algo- 
rithm. Member i first encrypts nii using a list of tempo- 
rary secondary public keys Zj, one for each member j, in 
reverse order zn , ■ ■ ■ , zi, to yield an intermediate cipherext 
C'i- Member i then encrypts C'i further using a list of pri- 
mary public keys yN, ■ ■ ■ ,yi to form a final ciphertext d. 

Member 1 collects all final ciphertexts into one list, then 
each member i in turn takes this list, strips off one layer 
of encryption using his primary private key Xi, randomly 
shuffles the list, and passes the result to rm+i. Member 
A'' broadcasts the final shuffled list to all members, each of 
whom verifies that the list includes her own intermediate ci- 
phertext C'i, and broadcasts a go if so and a no-go otherwise. 

Each member i, upon receiving a go from all members, 
broadcasts her secondary private key Wi associated with Zi, 
enabling all members to decrypt the shuffled messages. On 
receiving a no-go from any member, however, member i de- 
stroys her private key Wi and enters a blame phase, where 
all members reveal the secrets used to encrypt the interme- 
diate ciphertexts. Our shuffle protocol ensures integrity and 
anonymity exactly as in its precursor 0, but our new go/no- 
go and blame phases enable all group members to trace the 
culprit of any protocol malfunction. 

The shuffle protocol has two practical limitations: all mes- 
sages must be of equal length L, incurring 0{NL) extra 
communication if only one member wishes to send; and its 
decrypt-and-shuffle phase is inherently serial, incurring a 
long delay if A or L is large. We currently have no solution 
if TV is large, but our bulk protocol addresses the problem of 
sending large, variable-length messages efflciently. 

As illustrated in Figure [2] the bulk protocol uses the shuf- 
fie protocol to shuffle a set of N message descriptors, one 
submitted anonymously by one member, instead of shuffling 
the messages themselves. Each descriptor di contains the 
length Li of member i's message mi, a cryptographic hash 
of mi, a vector Si of N seeds Sij, each seed encrypted with 
j's primary public key and assigning j a pseudo-random bulk 
ciphertext to transmit, and a vector Hi of hashes Hij vali- 
dating each bulk ciphertext. 

Member i "assigns himself" a junk seed sa and a hash Ha 
of a ciphertext that, when XORed with the ciphertexts i 
"assigned" other members, yields i's message mi. Once the 
shuffle protocol has revealed the N shuffled message descrip- 
tors, representing an N x N matrix of bulk ciphertext "as- 
signments," group members send (in parallel) their assigned 
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Bulk transmission ciphertext bitstreams: 
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Figure 2: Illustration of bulk protocol operation for 3-member group, shuffled using permutation tt = [2,3,1]. 



ciphertexts to the designated target, enabling the target to 
recover and verify all members' messages. If any member 
produces an incorrect bulk ciphertext, a blame phase reruns 
the shuffle protocol, enabling the anonymous sender of the 
corrupted message to "accuse" and expose the culprit. 

2.5 Simplifying Assumptions 

Our core protocol descriptions in Sections [3] and 2] make 
several simplifying assumptions, which we will relax and ad- 
dress more realistically later in Section (5] We assume for 
now that: (a) all members know when to initiate a protocol 
run and how to distinguish one run from another; (b) all 
members of a group participate in every protocol run; (c) 
all members have public encryption keys and nonrepudiable 
signing keys known to all other members; and (d) all mem- 
bers remain connected throughout a protocol run and never 
stop sending correctly-signed messages, until the protocol 
run has completed from the perspective of all group mem- 
bers. Assumption (d) implies that we address only safety 
properties for now, deferring liveness issues to Section [5] — 
including the important corner case of a node withholding 
the last message it is supposed to send while collecting all 
other members' final messages, learning a protocol run's re- 
sults while denying others those results. 

3. SHUFFLE PROTOCOL 

This section details the shuffle protocol, first covering its 
cryptographic building blocks, then formally describing pro- 
tocol, proving its correctness, and analyzing its complexity. 

3.1 Cryptographic Primitives 

We use a standard, possibly randomized signature scheme 
consisting of: (a) a key generation algorithm producing a 
private/public key pair {u,v); (b) a signing algorithm tak- 
ing private key u and message m to produce signature a — 
SlG„{m}; and (c) a deterministic verification algorithm tak- 
ing public key v, message m, and candidate signature a, and 
returning true iff a is a correct signature of m using 11 's as- 



sociated private key u. The notation {mjsiGu indicates the 
concatenation of message m with the signature SlGu{m}. 

We also require a public-key cryptosystem, which must be 
IND-CCA2 secure [2] (e.g., RSA-OAEP [fg]). The cryp- 
tosystem consists of: (a) a key generation algorithm pro- 
ducing a private/public key pair {x,y); (b) an encryption 
algorithm taking public key y, plaintext m, and some ran- 
dom bits R, and producing a ciphertext C = {m}^; (c) a 
deterministic decryption algorithm taking private key x and 
ciphertext C, and returning the plaintext m. We assume 
a node can save the random bits R it uses during encryp- 
tion, and that it can encrypt deterministically using a given 
R, such that given inputs y, m, and R always yield the 
same ciphertext. Software cryptosystems using pseudoran- 
dom number generators generally satisfy this assumption. 
The notation C = {?ti}^/:^^ indicates iterated encryption 
via multiple keys: C = {. . . {m}^^ . . . . We omit R when 
an encryption's random inputs need not be saved. 

We use the standard definition [ST] of an unkeyed hash 
function and will denote the hash of message m as HASH{m}. 

We use a standard definition [31] of a pseudo-random bit 
generator. We will denote the first L bits generated from a 
pseudo-random bit generator seeded with s as pb.f{L, s}. 

3.2 Formal Protocol Description 

Each member i (for i = 1, . . . , A'') has a primary encryp- 
tion key pair {xi,yi), a signing key pair (ui, Vi), and a secret 
datum di of fixed length L to send anonymously. 

Before a protocol run, all members agree on a session 
nonce ur uniquely identifying this protocol run, the par- 
ticipants' primary public encryption and signing keys, and a 
common ordering of all members 1, . . . , A^. Such agreement 
might be achieved via Paxos [21] or BFT [6]. 

The shuffle protocol operates in phases; each member i 
sends at most one message per phase 4>, though i may 
broadcast the same rrn^ to several members. Each member 
maintains a tamper- evident log of all messages it sends and 
receives in a protocol run [19]. Member i signs each rui^ it 
sends with its private key Ui, and includes in each message 
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the session nonce na and a hash of i's current log head in 
phase (j). Each /i^ depends on all messages i received up to 
phase (j) before sending rrii^. Members ignore any messages 
they receive containing a bad signature or session nonce. 

• Phase 1: Secondary Key Pair Generation. Each member 
i chooses an encryption key pair {wi, Zi), and broadcasts: 

{zi,nR, hi}siGui 

• Phase 2: Data submission. Each member i encrypts her 
datum di with all members' secondary public keys: 

Member i stores Ci for later use, then further encrypts 
C'i with all members' primary public keys, this time in- 
ternally saving the random bits used in each encryption: 

Member i now sends to member 1: 

{Ci,nR,h2}siGui 

• Phase 3: Anonymization. Member 1 collects all cipher- 
texts into a vector Co = Ci, . . . , Cjv, randomly permutes 
its elements, then strips one layer of encryption from each 
ciphertext using private key xi to form Ci. Member 1 
sends to member 2: 

{Ci,nR,h3}siGui 

Each member 1 < i < A'^ in turn accepts d-i, permutes 
it, strips one encryption layer to form Ci, then sends Ci to 
member i + 1. Member N finally permutes and decrypts 
Cn-1 to form Cn, and broadcasts to all members: 

{Cat, Ur, /13}SIG„. 

If any member i detects a duplicate or invalid cipher- 
text during this phase, member i reports it and the group 
moves directly to phase 5b below ("blame"). 

• Phase 4: Verification. All members now hold Cn, which 
should be a permutation of Ci, . . . , C'^- Each member i 
verifies that her own C,' is included in Cjv, sets a flag GOi 
to TRUE if so and FALSE otherwise, and broadcasts: 

{COi, HASh{Cjv}, Ur, /l4}SIGui 

Each member i then waits for such a "go/no-go" message 
from aZZ other members. If every member j reports GOj — 
TRUE for the correct hash{(7jv}, then member i enters 
phase 5a below; otherwise i enters phase 5b. 

• Phase 5a: Decryption. Each member i destroys her copy 
of C'i and the random bits she saved in phase 2, then 
broadcasts her secondary private key Wi to all members: 

{wi,nR, /isjsiGu; 

Upon receiving all keys wi, ... ,wn, member i checks that 
each Wj is the private key corresponding to public key Zj , 
going to phase 5b if not. Member i then removes the 
remaining N levels of encryption from Cn, resulting in a 
permutation of the submitted data di, . . . , djv. 

• Phase 5b: Blame. Each member first destroys her sec- 
ondary private key Wi, then reveals to all members the 
random bits Rtj she saved from the primary public key 
encryptions in phase 2, and all signed messages she re- 
ceived and sent in phases 1-4. Each member i uses this 



information to check the behavior of each member j in 
phases 1-4, replaying j's primary key encryptions in phase 
2 and verifying that j's anonymized output Cj in phase 3 
was a decrypted permutation of Cj-i. Member i exposes 
member j as faulty if j signed an invalid Zj in phase 1, 
an incorrectly encrypted Cj in phase 2, an improperly de- 
crypted or permuted Cj in phase 3, a GOj = FALSE or a 
wrong hash{(7]v} in phase 4 after phases 1-3 succeeded, 
an incorrect Wj in phase 5a; or if j equivocated by signing 
more than one message or log head in any phase (p. 

3.3 Proofs of Correctness 

The shuffle protocol's integrity and anonymity derive al- 
most directly from Brickell/Shmatikov [5], so we only sketch 
proofs of these properties, focusing instead on the account- 
ability property introduced by our enhancements. 

3.3.1 Integrity 

To preserve integrity, after a protocol run every honest 
member must either: (a) hold the datum di of every honest 
member i, or (b) know that the protocol did not complete 
successfully. Suppose that a protocol run appears to com- 
plete successfully via phase 5a (decryption), but some honest 
member i does not hold the plaintext dj of some other hon- 
est member j. Since j is honest, j's intermediate ciphertext 
Cj must be a correct encryption of dj, and Cj must have 
appeared in Cn, otherwise j would have sent GO-, = FALSE 
in phase 4. Since honest member i would not enter phase 
5a without receiving GOj = true for the same Cn from 
all members, member i must hold Cj , and Cj must decrypt 
to dj if all members released correct secondary private keys 
wi, . . . ,wn during phase 5a. If some faulty member released 
an incorrect key w'^. 7^ Wfe, all honest members see that uij, 
does not match k's public key Zk and know that k is faulty. 

3.3.2 Anonymity 

The protocol preserves integrity if no group of fc < A — 2 
colluding members can win an anonymity game, determin- 
ing which of two honest members submitted which of two 
plaintexts, with non- negligible probability [5]. The attacker 
might gain advantage either by manipulating protocol mes- 
sages, or by using only the information revealed by a correct 
protocol run. In the first case, the attacker can identify the 
intermediate ciphertext Cl of some honest member i by du- 
plicating or eliminating other honest members' ciphertexts 
in phase 3, but any honest member will detect duplication 
in stage 3 and elimination in stage 4, aborting the protocol 
before the attacker can decrypt C,'. In the second case, an at- 
tacker who can win the anonymity game with non-negligible 
probability, using only information revealed by correct pro- 
tocol runs, can use this ability to win the distinguishing game 
that defines an IND-CCA2 secure cryptosystem [2l[5]. 

3.3.3 Accountability 

A member i exposes another member j in phase 5b (blame) 
if i obtains proof of j's misbehavior verifiable by a third 
party. To maintain accountability, no member may expose 
an honest member, and at the end of a protocol run, ei- 
ther: (a) the protocol completes successfully, or (b) all hon- 
est members expose at least one faulty member. 

We first show that no member i can expose an honest 
member j. A proof of misbehavior by j consists of some 
"incriminating" message rrijtf, signed by j in phase 4>, together 
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with all of the messages in j's log up through phase 0, and 
the random bits each node saved during phase 2 and released 
in phase 5b. Member i could "truthfully" expose j only if 
j signs an incorrect message in phases l-5a, or signs more 
than one message per phase, contradicting the assumption 
that j is honest. Member i could also falsely accuse j by 
exhibiting one of j's messages rrij^, together with a false 
"prior" message mj,^/ (for 0' < (f>) signed by some colluding 
node k, different from the message 171^4,' that j actually used 
to compute her message rrij^. In this case, the "proof" will 
contain both m^^/ (from j's log) and the false m'f,^, , exposing 
the equivocating member k instead of honest member j. 

Now suppose a protocol run fails, but some honest mem- 
ber i does not expose any faulty member in the blame phase. 
Member i enters the blame phase only if it: (a) detects a 
faulty encryption key in phase 1, (b) detects a duplicate or 
faulty ciphertext in phase 3, (c) sees a GO-, = FALSE in phase 
4, (d) sees an incorrect hash{(7jv} in phase 4, (e) detects a 
bad secondary private key in phase 5a. Cases (a) and (e) 
immediately expose the relevant message's sender as faulty. 

In case (b), member i can encounter a duplicate ciphertext 
in phase 3 only if some member 1 < j < i injected it earlier 
in the anonymization phase, or if two members ji and j2 col- 
luded to inject it in phase 2. (Two independently encrypted 
ciphertexts are cryptographically unique due to the random 
bits used in encryption.) If some member 1 < j < i dupli- 
cated a ciphertext, then using the message logs of members 
1 through i and the random bits from phase 2, member i 
can replay the decryptions and permutations of each mem- 
ber before i in phase 3 to expose j as faulty. If no member 
duplicated a ciphertext in phase 3, then in replaying phase 
3, i finds the senders of the ciphertexts Cj^ and Cjj decrypt- 
ing to identical ciphertexts in d^i, exposing ji and _j2. If 
i cannot decrypt a ciphertext in phase 3, it similarly traces 
the bad ciphertext to the member responsible. 

In case (c) above, either the sender j of the GOj = FALSE 
truthfully reported its ciphertext missing in phase 4, or sent 
GOj = FALSE although its intermediate ciphertext Cj ap- 
peared in Cjv. In the former case, i replays phase 3 to ex- 
pose the member who replaced j's ciphertext. In the latter 
case, the occurrance of C'j in Cjv exposes j itself. 

In case (d), member i's Cjv does not match the hash{CJv} 
in another member j's go/no-go (Cjv 7^ C'^^). Members i and 
j compare message logs, revealing that either i or j is lying 
about the message member A'^ sent in phase 3, or member 
A'^ sent two signed messages in phase 3, exposing i, j, or A''. 

3.4 Complexity 

If the underlying network provides efficient broadcast, then 
each node transmits 0{NL) bits, for a total communication 
cost of 0{N^L). Without efficient broadcast, the "normal- 
case" phases 1 through 5a still require each node to transmit 
only 0{NL) bits, for 0{N'^L) overall cost, because all broad- 
casts in these phases are either single messages of length 
0{NL) or A'' messages of length 0{L). The blame phase in 
an unsuccessful run may require 0{N^L) total communica- 
tion for all honest members to expose some faulty member, 
but an attacker can trigger at most 0{N) such runs before 
the group exposes and removes all faulty members. 

Protocol latency is dominated by the N serial commu- 
nication rounds in phase 3, in which each node must send 
0{NL) bits, for a total latency of 0{N^L) transmission bit- 



times. Other phases require a constant number of unicast 
messages or parallelizable broadcasts. 

Excluding the blame phase, each member's computational 
cost is dominated by the 2A'' encryptions it must perform in 
phase 2, each processing plaintexts of length 0{L + N) due 
to plaintext expansion during iterated encryption, for an 
overall cost of 0{N'' + NL) per node or 0(A/^ -|- A^^L) total. 
The blame phase introduces an additional 0{N) factor if all 
members must replay all other members' encryptions. 

4. BULK PROTOCOL 

We now describe Dissent's bulk protocol formally, prove 
its correctness and security, and analyze its complexity. 

4.1 Formal Description 

Members 1, . . . , A'' initially hold messages mi, . . . , mjv, now 
of varying lengths Li, . . . , Ln ■ As before, each member i has 
a signing key pair (ui , Vi ) and a primary encryption key pair 
{xi,yi); all members know each others' public keys, and have 
agreed on session identifier ur and an ordering of members. 

• Phase 1: Message Descriptor Generation. Each member 
i chooses a random seed Sij for each member j, then for 
each j ^ i, computes the first Li bits of a pseudo-random 
function seeded with each Sij to obtain ciphertext dj: 

C\j = PRF{ii, Sij} (j / i) 

Member i now XORs her message rrii with each dj for 
j ^ i to obtain ciphertext Ca: 

Cii = Ci e . . . e Ci(i_i) e mi e c^i+i^ e . . . e 

Member i computes Hij — HASH{Cij}, encrypts seed Sij 
with j's public key to form Sij = {sij}^j\ and collects 
the Hij and Sij for each j into vectors Hi and Si: 

Hj = Hii, . . . , HiN 

Si = 5*^1 , . . . , SiN 

Finally, member i forms a message descriptor di: 
di = {L,,HASH{m,},-ffi,S,} 

• Phase 2: Message Descriptor Shuffie. The group runs the 
shuffle protocol in Section |31 each member i submitting 
its fixed- length descriptor di. The shuffle protocol broad- 
casts all descriptors in some random permutation n to all 
members, so di appears at position n{i) in the shuffle. 

• Phase 3: Data transmission. Each member j now recog- 
nizes his own descriptor dj in the shuffle, and sets Cjj = 
Cjj. From all other descriptors di (i 7^ j), j decrypts Sij 
with private key Xj to reveal seed Sij , computes ciphertext 
dj — PRF{Li,Sij}, and checks HASH{Cij} against Hij. If 
decryption succeeds and the hashes match, member j sets 
dij = dj. If decryption of Sij fails or HASH{Cij} / Hij, 
then j sets C'ij to an empty ciphertext, C'ij = {}. 

Member j now signs and sends each C[j to the designated 
target for the protocol run, in vr-shuffled order: 

• Phase 4: Message Recovery. The designated target (or 
each member if the target is the whole group) checks each 
C'ij it receives from member j against the correspond- 
ing Hij from message descriptor di. If C'ij is empty or 
HASH{Cij} 7^ Hij, then message slot 7r(i) was corrupted 
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and the target ignores it. For each uncorrupted slot Tv{i), 
the target recovers i's message by computing: 

rrii = C-i © ... ® C-jv 

• Phase 5: Blame. If any messages were corrupted in phase 
131 all members run the shuffle protocol again, in which 
each member i whose message was corrupted anonymously 
broadcasts an accusation naming the culprit member j: 

Each accusation contains the seed Sij that i assigned j and 
the random bits i used to encrypt the seed. Each mem- 
ber k verifies the revealed seed by replaying its encryption 
Sij = {sij}y-^ , and checks that Hij — HASH{pRF{Li, Sjj}}; 
if the accusation is valid, then each k exposes j as faulty. 
If the shuffle reveals no valid accusation for a corrupted 
message slot 7r(i), then k does nothing: either the anony- 
mous sender i has corrupted his own message or has cho- 
sen not to accuse the member who did, which is essentially 
equivalent to i sending a valid but useless message. 

4.2 Proofs of Correctness 

We now show that the bulk protocol provides integrity, 
anonymity, and accountability as defined in Section [2.31 

4.2.1 Integrity 

The shuffle protocol ensures that the message descriptor 
di of each honest member i is correctly included in the shuf- 
fled output. The target can then use either the individual 
ciphertext hashes Hij or the cleartext hash HASHjmi} from 
di to verify the integrity of i's message in the bulk output. 
The cleartext hash HASH{mi} is technically redundant, but 
it enables all members to verify the final results if only one 
node collects and combines the ciphertexts for efflciency. 

4.2.2 Anonymity 

Suppose an attacker controls all but two honest members 
i and j, and wishes to win the anonymity game [5] by deter- 
mining with non-negligible advantage over random guessing 
which honest member sent one of their plaintexts, say rrii. 
The attacker knows which two message slots 7r(i) and n{j) 
belong to the honest members, and must find the exact per- 
mutation TV. Since the shuffle protocol preserves anonymity 
(Section 13. 3. 2p and the shuffled message descriptors depend 
only on random bits and the messages themselves, the at- 
tacker learns nothing about tt from the message descriptors. 
The only other information the attacker obtains about rrii 
are the ciphertexts Cj'fe produced by all members k. But 
since each bit of C'a and C'ij is encrypted with a pseudo- 
random one-time pad generated from a seed Sij that only i 
and j know, the attacker learns nothing from these bits. 

4.2.3 Accountability 

Suppose the bulk protocol violates accountability, imply- 
ing that at the end of a protocol run, there is some honest 
member j who does not hold the plaintext of another hon- 
est member i and does not expose any dishonest member. 
Since the shuffle protocol maintains accountability, member 
j must have received i's message descriptor di. Since i is 
honest, di contains correctly computed hashes Hik and cor- 
rectly encrypted seeds Sik for ciphertexts Cj'j. that, XORed 
together, would reveal i's message rrii to j. Some member k 
must therefore have sent an incorrect ciphertext in the bulk 



phase. But since i is honest, i would have sent a correct 
accusation of k in the blame phase, exposing k as faulty. 

4.3 Complexity 

With efflcient broadcast, in the normal case each mem- 
ber transmits 0{N^) bits to shuffle A'^ message descriptors 
of length 0{N), then sends Ltot + 0{1) bits in the data 
transmission phase, where Ltot ~ Normal-case com- 

munication complexity is thus 0{N'^) + Ltot bits per node. 
An unsuccessful run may transmit 0{N'^) + Ltot bits per 
node due to the shuffle protocol's blame phase. 

If A'' is small so that message length Ltot dominates, if 
only one member wishes to transmit {Li = Ltot and Lj = 
for j 7^ i), and the transmitted data is incompressible, then 
Dissent's communication efficiency is asymptotically opti- 
mal for our attack model: any member sending o{Ltot) bits 
cannot be the sender, a trivial traffic analysis vulnerability. 

The shuffie protocol incurs an OIN"^) startup latency, as 
the A'^ nodes serially shuffie A'^ descriptors of length 0{N), 
but the data transmission phase is fully parallelizable, for a 
total latency of 0{N^ + Ltot) transmission bit-times. 

Each member i performs A'^ cryptographic operations on 
0{N) bits each during the shuffie, N operations on Li bits 
to compute Ca, and one operation on Lj bits to compute 
Cij for each j ^ i. The protocol's computational complexity 
is thus 0{N'^ + NLtot) per node. 

5. USAGE CONSIDERATIONS 

In describing Dissent's shuffie and bulk protocols, we made 
a number of simplifying assumptions, which we now address 
by placing these core protocols in the context of a more re- 
alistic, high-level "wrapper" protocol. We merely sketch this 
wrapper protocol without formal definition or analysis, since 
it is intended only to illustrate one way to deploy Dissent 
in a realistic environment, and not to define the "right" way 
to do so. The wrapper protocol addresses five practical is- 
sues: protocol initiation, member selection, deniable keying, 
liveness assurance, and end-to-end reliability. 

5.1 Protocol Initiation 

Our shuffle and bulk protocols assume that all group mem- 
bers "just know" when to commence a protocol run, but in 
practice some node must initiate each run. Members must 
not initiate a protocol run out of a desire to send anony- 
mously, however, since doing so would make the sender's 
identity obvious to traffic analysis. 

In our wrapper protocol, therefore, each protocol run is 
unilaterally initiated by some node, whom we call the leader. 
To enable members to send "spontaneously" without com- 
promising their anonymity, every group member periodi- 
cally initiates a protocol run independently of its own de- 
sire to send, on either a fixed or randomized time schedule. 
(Anonymity would be equally well served if the leader was 
the same for all protocol runs, but requiring every mem- 
ber to act as leader occasionally makes it easier to address 
liveness issues discussed below.) If group policy permits, a 
non-anonymous outsider may also lead a protocol run, ef- 
fectively invoking the collective services of the group as in 
anonymous data-mining applications [5]. 

5.2 Selecting Available Participants 

The core protocols above assume that every group mem- 
ber participates in a given protocol run, but in practice at 
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least a few members of a long-lived group are likely to be 
unavailable at any given time, making it pragmatically im- 
portant for the group to be able to make progress in the 
absence of a few members. The wrapper protocol there- 
fore distinguishes a group's long-term membership M from 
the set of members Mr participating in a particular run R, 
where Mr C M. In the wrapper protocol, the leader of run 
R is responsible for detecting which members are presently 
available and bringing those available to a consensus on the 
precise set of participants Mr for run R. 

A key issue in choosing A^r is preventing a malicious 
leader from packing Mr with colluding members to the 
exclusion of most honest members, limiting the anonymity 
of the few honest members remaining. Group policy must 
therefore define some minimum quorum Q, and honest nodes 
refuse to participate in any proposed protocol run where 
\Mr\ < Q. If there are at most f < Q — 2 faulty nodes, 
therefore, then honest nodes are always guaranteed at least 
{Q ~ /)-anonymity regardless of how Mr is chosen. 

As a further defense, honest members might actively pro- 
tect each other against malicious exclusion as follows. If 
honest member i receives a proposal from would-be leader 
Ir to initiate run R while excluding some other member j, 
but i believes j to reachable, then i demands that Ir add j to 
Mr — forwarding messages between Ir and j if necessary — as 
a precondition on i participating in round R at all. 

5.3 Coercion Resistance via Deniable Keying 

Dissent's shuffle protocol assumes each group member i 
has and a signing key pair {ui,Vi) with which it signs all mes- 
sages, creating the nonrepudiable "accountability trail" that 
the blame phase (5b) requires to trace a misbehaving mem- 
ber. Unfortunately, this nonrepudiable record could also en- 
able members to prove to a third party which message they 
sent (or didn't send) in a given protocol run. In anonymous 
communication scenarios we often desire not just anonymity 
but also repudiability [4]: after a protocol run, no one should 
be able to prove to a third party which message any mem- 
ber sent, or ideally, whether a member participated at all. In 
anonymous voting applications, we often desire the closely 
related property of resistance to coercion or "vote-buying." 

Our wrapper protocol can provide a form of repudiabil- 
ity or coercion resistance as follows. We assume each group 
member i's well-known identity is defined only by its pri- 
mary encryption key pair {xi, tji), and members now choose 
a fresh, temporary signing key pair {ui,Vi) for each protocol 
run. To initiate a run, the would-be leader I uses a deniable 
authenticated key exchange algorithm such as SKEME [21] 
to form a secure channel with each potential participant i, 
using Z's and z's primary encryption keys for authentication. 
Each member i uses this pairwise-authenticated channel to 
send the leader i's fresh public signing key Vi for the run. 

Once / forms a tentative list of A'' = \Mr\ participants, 
I broadcasts to all participants a round descriptor Dr con- 
taining a timestamp, all participants' primary public keys 
j/i , . . . , yjv , and all participants' corresponding temporary 
signing keys vi, . . . ,vn for the run. Each member i now 
forms a challenge Cij for each node j, containing a random 
nonce Nij and a hash of Dr keyed on Nij. Member i then 
encrypts Cij with j's public key tjj to yield dj. Member i 
sends its encrypted challenges to the leader, who forwards 
each Cij to member j. Member j decrypts dj, verifies the 
keyed hash it contains against the Dr that j received from 



the leader, and returns dj to the leader, who forwards it to 
i. On a decryption failure or challenge mismatch, the leader 
must decide whether to exclude i or j from a retry attempt; 
i can prove its innocence by revealing the random bits it 
used to encrypt its original challenge to j. 

Once all members confirm Dr, with all other members, the 
shuffle protocol proceeds using the temporary signing keys in 
Dr. These signing keys provide nonrepudiation only within 
the protocol run, allowing the leader to trace misbehaving 
members and exclude them from subsequent runs. No node 
is left with proof that any member i actually used signing key 
Hi during a given run, however, since anyone can unilaterally 
forge all the authenticated key exchanges, challenges, and 
subsequent messages in the shufHe and bulk protocols. 

Of course, this form of repudiability is useful only against 
an attacker who actually requires third-party verifiable "proof 
of responsibility" in order to coerce group members. If the 
attacker can see all network traffic, as our attack model as- 
sumes, anrf the attacker's traffic logs alone constitute "proof" 
of which network packets a given member sent, then we know 
of no way to achieve deniability or coercion resistance. Sim- 
ilarly, a member might be coerced before a protocol run into 
sending some sufficiently unique, attacker-supplied message 
or ballot; if the mere appearance of that message/ballot 
in the run's output satisfies the attacker that the mem- 
ber "stayed bought," then no anonymity mechanism based 
purely on a random shuffie will address this form of coercion. 

5.4 Ensuring Liveness 

As we have seen, tracing active disruptors of the shuffie or 
bulk protocols presents particular technical challenges due 
to the need to protect the anonymity of honest senders. A 
member might passively disrupt either protocol, however, by 
simply going offline at any time, either intentionally or due 
to node or network failure. Fortunately, given the core pro- 
tocols' resistance to both active disruption and trafflc anal- 
ysis, we can ensure liveness and handle passive disruption 
via more generic techniques. 

Each phase of the shuffle and bulk protocols demand that 
particular members send properly signed messages to other 
members. Again borrowing terminology and ideas from Peer- 
Review [19] , when the protocol demands that member i send 
member j a message, and member j has not received such 
a (properly signed) message for some time, we say that j 
suspects i. Once j suspects i, j informs another node k (the 
leader, for example) of j's suspicion; k in turn contacts i 
demanding a (signed) copy of i's message to j. If i fails to 
offer this message to k, then after some time k suspects j as 
well and notifies other members in turn, eventually causing 
all honest, connected members to suspect i. Member i can 
dispel any honest member's suspicion at any time by offer- 
ing a copy of the demanded message. If i honestly cannot 
send to j due to asymmetric connectivity, for example, then 
i responds to fc's demand with the required message, which 
k forwards back to j, dispelling both j's and fc's suspicion 
and enabling the protocol to proceed. 

Since our wrapper protocol makes the leader responsible 
for initiating protocol runs, we also make it the leader's re- 
sponsibility to decide when a protocol run has failed due 
to a suspected node going offline — or deliberately withhold- 
ing a required message — for too long. At this point, the 
leader starts a new protocol run, excluding any exposed or 
persistently suspected nodes from the previous run, and the 
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remaining members attempt to resend their messages. If the 
leader fails, members can retry their sends in a future run 
initiated by a different leader. 

5.5 End-to-End Reliability 

A corner-case liveness challenge for most protocols is clo- 
sure, or determining when participants may consider the 
protocol "successfully concluded." In a byzantine model, 
a malicious member might intentionally withhold the last 
message he was supposed to send — e.g., his own secondary 
private key in phase 5a of the shuffle protocol, or his own ci- 
phertext in the bulk protocol — while collecting the last mes- 
sages of other members, thereby learning the results of the 
protocol run while denying those results to other members. 

We approach this class of problems in general by treating 
our shuffle and bulk protocols as a "best-effort" anonymous 
delivery substrate, atop which some higher-level protocol 
must provide end-to-end reliable delivery and graceful clo- 
sure if desired. If a faulty member denies other members 
a protocol run's results, the honest members will soon sus- 
pect the faulty member, and the same or a different leader 
will eventually start a new protocol run without the faulty 
member, in which the members may retransmit their mes- 
sages. If a member i wishes to ensure that a message he 
sends anonymously is reliably seen by a particular member 
j, i must resend the message in successive protocol runs 
until j acknowledges the message. (Member j might sign 
acknowledgments via either a public or pseudonymous key). 

If the messages sent in a protocol run are interrelated, 
such as the ballots comprising an anonymous vote, and the 
group wishes to ensure that some quorum of members see 
the result, then the group can follow the voting run with 
an acknowledgment run, discarding and repeating unsuc- 
cessful votes (with successively smaller membership sets if 
members go offline) until the required number of members 
acknowledge the results. If the group wishes to provide reli- 
able broadcast semantics or maintain some consistent group 
state across successive protocol runs, the group can imple- 
ment byzantine consensus [6] atop the shuffled send primi- 
tive, ensuring both liveness and strong consistency as long 
as over two thirds of the group members remain live. 

6. PROTOTYPE IMPLEMENTATION 

To evaluate Dissent's practicality, we built and tested a 
simple prototype of the protocol. The prototype is written in 
Python, using OpenSSL's implementations of 1024-bit RSA- 
OAEP with AES-256 for public-key encryption and signing, 
AES-256 in counter mode as the bulk protocol's pseudo- 
random function, and SHA-l as the hash algorithm. 

We used the Emulab [TS] network testbed to test the pro- 
totype under controlled network conditions. We ran the 
prototype on recent x86 PCs machines running Ubuntu 7.04 
and Python 2.5, on a simulated star topology in which every 
node is connected to a central switch via a 5Mbps connec- 
tion with a latency of 50ms (100 ms node-to-node latency). 
We make no claim that this topology is "representative" of 
likely deployment scenarios for Dissent, since we know of no 
data on the network properties "typical" online groups that 
might wish to run Dissent. Our simulated topology is merely 
intended to reflect plausible communication bandwidths and 
delays for wide-area Internet communication. 

We rely on the formal analysis in previous sections to eval- 
uate Dissent's security properties, and assume that the ac- 



countability measures in a full implementation of Dissent 
will deter or eventually exclude misbehaving members. For 
experimentation purposes, therefore, we implement and test 
only the "normal-case" aspects of the protocol in the current 
prototype. The prototype does not use a secure public key 
infrastructure, and does not implement the "blame" phases 
or the wrapper protocol. Nodes sign and verify all mes- 
sages, however, ensuring that performance measurements 
accurately reflect Dissent's normal-case costs. 

The prototype uses TCP for communication, maintaining 
TCP connections throughout a given protocol run to min- 
imize startup overhead, but closing all connections at the 
end of each run. Where Dissent requires broadcast, nodes 
implement these broadcasts atop TCP by sending their mes- 
sages to a leader, who bundles all broadcasts for that phase 
and sends each node a copy of the bundle. 



6.1 Performance Evaluation 

Figure [3] shows the total time the prototype requires to 
broadcast messages of varying sizes anonymously among 16 
nodes, using either the shuffle protocol alone or the full Dis- 
sent protocol. In each case, we test two message loads: a 
Balanced load in which each node sends l/16th of the to- 
tal message data, and a OneSender load in which one node 
sends all the data and other nodes send nothing. 

For a single node to send a 16MB message. Dissent runs 
in about 31 minutes, or 3.6 x longer than one node requires 
to broadcast the same data to the other 15 nodes with no 
encryption or anonymization. While significant, we feel this 
is a reasonable price to pay for strong anonymity. 

As expected, the full protocol incurs a higher startup de- 
lay than the shuffle protocol alone, but handles unbalanced 
loads more gracefully, maintaining similar performance for a 
given total message length regardless of balance. We are not 
aware of any other verifiable shuffles |17II22) for which work- 
ing implementations and performance data are available, but 
given their typical assumption of small, equal-length mes- 
sages, we expect their performance on unbalanced loads to 
be at best on par with our shuffle protocol alone. 

Figure 2] breaks the runtime of the full Dissent protocol 
into its shuffle and bulk protocol components, illustrating 
that the shuffle's cost remains constant with message size 
and becomes negligible as total message length grows. 

The full Dissent protocol still shows some slowdown un- 
der highly unbalanced load: although balance does not af- 
fect Dissent's communication cost, it does affect computa- 
tion costs. When only one node is sending, that node must 
compute and XOR together — 1 pseudo-random streams 
of message length L, while other nodes each compute only 
one L-byte stream. This timing difference could lead to a 
side-channel attack if not handled carefully in implementa- 
tion, e.g., by pre-computing all required bit strings before 
commencing a send. We have made no attempt to analyze 
the protocol in detail for side-channel attacks, however. 

Figure [S] measures the prototype's runtime with varying 
group sizes. In a successful run, each node sends 0{N^) bits 
in the shuffle and Ltot + 0(1) bits in the bulk protocol. As 
expected, the shuffle's runtime increases much more quickly 
with A'' than the bulk protocol, although the superlinear A^^ 
curve manifests only slightly for the small groups we tested. 
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Figure 3: Time required for anonymous broadcast 
of balanced and unbalanced message loads among 
16 nodes, via shuffle alone or full Dissent protocol. 



Figure 5: Time required to send 1MB of data (bal- 
anced) using shuffle and bulk transfer protocols to- 
gether with a varying group size. 
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Figure 4: Time required to send varying message 
sizes, broken into shuffle and bulk transfer protocol 
portions. 



7. RELATED WORK 

Dissent's shuffle protocol builds directly on Brickell and 
Shmatikov's data collection protocol adding DoS resis- 
tance via our new go/no-go and blame phases. Dissent's 
bulk protocol is similarly inspired by DC-nets [8], which 
are a computationally efficient and provide unconditional 
anonymity, but traditionally require nondeterministic "reser- 
vation" schemes to allocate the anonymous channel's com- 
munication bandwidth, and are difflcult to protect against 
anonymous DoS attacks by group members. Strategies ex- 
ist to strengthen DC-nets against DoS attacks [36], or to 
form new groups when an attack is detected [28]. Dissent's 
use of a shuffle protocol to set up a deterministic DC-nets 
instance, however, cleanly avoids these DoS vulnerabilities 
while providing the additional guarantee that each member 
sends exactly one message per protocol run, a useful prop- 
erty for holding votes or assigning 1-to-l pseudonyms. 

Mix-networks [7] provide scalable and practical anony- 
mous unicast communication, and can be adapted to group 
broadcast [21]. Unfortunately, mix-networks are difficult to 
protect against traffic analysis [27] and DoS attacks [13II20| . 
and in fact lose security under DoS attack [3]. Crowds [25] 
are more computationally efficient that mix networks, but 
are vulnerable to statistical traffic analysis when an attacker 
can monitor many points across the network. Dissent in con- 
trast is provably secure against traffic analysis. 

Anonymous voting protocols solve a problem that closely 
relates to the group broadcast problem. Each user casts a 



ballot whose contents should be publicly known but whose 
author should be unknown to both the election officials and 
other voters. Many voting protocols allow transmission of 
only fixed- length "Yes" or "No" messages [1]. 

Cryptographically verifiable shuffles [17II22| might be used 
in place of our shuffle protocol, allowing shuffles to be per- 
formed and verified offline. These algorithms require more 
complex calculations, however. Further, guaranteeing not 
only a shuffle's correctness, but also its randomness and 
hence anonymity in the presence of compromised members, 
still requires passing a batch of messages through a series of 
independent shuffles, as in Dissent or mix-networks |12) . 

Other relevant schemes for group-oriented anonymity in- 
clude ring signatures [26] , which provide no protection against 
traffic analysis, and fe-anonymous message transmission pro- 
tocols [35] , which provide anonymity only when a large frac- 
tion of group members are honest. 

Tor [Tl] and Herbivore [28] are two well-known practi- 
cal systems for providing anonymous communication over 
the Internet. These systems scale to far larger groups than 
Dissent does, and also permit interactive communication. 
These systems do not provide Dissent's strong guarantees 
of anonymity or accountability, however. As a system based 
on mix networks. Tor is vulnerable to traffic analysis attacks. 
Herbivore provides unconditional anonymity, but only within 
a small subgroup of the total group of participants. Dissent 
may be more suitable for non-interactive communication 
between participants willing to sacrifice protocol execution 
speed for strong assurances of anonymity and accountability. 



8. CONCLUSION 

Dissent is a novel protocol for anonymous and accountable 
group communication. Dissent allows a well-known group of 
participants to anonymously exchange variable-length mes- 
sages without the risks of traffic analysis or anonymous DoS 
attacks associated with mix-networks and DC-nets. Dissent 
improves upon previous shuffled-send primitives by adding 
accountability - the ability to trace faulty nodes - and by 
eliminating the message padding requirements that limit 
earlier schemes. We have reviewed the practical concerns 
associated with a real- world deployment of Dissent, and we 
have proposed possible solutions for each. Our implementa- 
tion demonstrates that Dissent is a practicable protocol, at 
least for a medium-sized group of participants. 
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